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L9: Entry 10 of 11 File: USPT Aug 8, 2000 



DOCUMENT-IDENTIFIER: US 6101180 A 

TITLE: High bandwidth broadcast system having localized multicast access to 
broadcast content 



Detailed Description Text (99) : 

The controller unit 440 handles software downloads for itself and for all of the 
transponder units 445. Software downloads are preferably performed using FTP file 
downloads over the local ISP LAN the 24 0 through NIC 4 67, from a remote station 
over the modem interface 470, or through the RS-232 port 487. Before a file is 
downloaded, FTP server software in the controller unit 440 verifies that the 
download is, in fact, a new file. The files are preferably downloaded into a fixed 
directory structure. 

Current US Cross Reference Classification (7) : 
709/203 
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[57] ABSTRACT 

A method of multicasting digital data to a user accessing an 
Internet connection is disclosed. The method includes plac- 
ing digital data that is to be multicast in IP protocol to 
generate IP digital data. The IP digital data is transmitted 
from a transmission site to a remote Internet point of 
presence through a dedicated transmission channel substan- 
tially separate from Internet backbone. The dedicated trans- 
mission channel may be, for example, a satellite channel. At 
the remote Internet point of presence, the IP digital data is 
multicast for delivery to at least one receiving Internet user's 
apparatus connected to but distal from the remote Internet 
point of presence. 

8 Claims, 33 Drawing Sheets 
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File: USPT 



Oct 26, 1999 



DOCUMENT-IDENTIFIER: US 5974547 A 

TITLE: Technique for reliable network booting of an operating system to a client 



Brief Summary Text (19) : 

While the boot process is occurring but prior to the availability of any client 
0/S-based network support, client hard disk emulation occurs through appropriate 
calls made to an interrupt (Interrupt 13 or simply "Int 13") handler. Through such, 
calls, appropriate sectors in the client image file are initially downloaded, via a 
real-mode network adapter ( NIC ) driver and the Int 13 Handler to remotely install 
various components of the O/S into client PC. The actual client hard disk emulation 
process is provided through a real mode procedure that executes as part of Int 13 
Handler. In essence, the real mode procedure determines, based on values of status 
flags, whether the client 0/S is then capable of handling a network request for 
sector access of the client image file. If the client 0/S has not then progressed 
to that point in its boot process, the real mode procedure processes that request, 
in real mode, through the Int 13 Handler. 

Detailed Description Text (14): 

As shown, client PC 10 comprises input interfaces (I/F) 310, processor 320, NIC 
360, memory 330 and output interfaces 340, all conventionally interconnected by bus 
350. Memory 330, which generally includes different modalities, includes 
illustratively random access memory (RAM) 332 for temporary data and instruction 
store, diskette drive (s) (not specifically shown) for exchanging information, as 
per user command, with floppy diskettes, and non-volatile mass store 335 that is 
implemented through hard disk drive (s) 334, typically magnetic in nature. Should 
client PC 10 be implemented by "diskless" computer, then all disk drives, including 
both floppy diskette drive (s) and hard disk drive (s) 334, would be omitted. 
Regardless of whether client PC 10 contained a hard disk drive or not, the client 
0/S, during its boot process, would be downloaded into RAM 332 and executed 
therefrom. As shown above in FIG. 2A, NIC 360 contains internal read-only memory 
362, that stores network boot code 364. This code, as will be discussed shortly 
below, once downloaded into RAM 332 on power-up permits the NIC to establish a 
network connection to a remote server. 

Detailed Description Text (19): 

Once a user has powered-up client PC 10, as symbolized by block 420, the stored ROM 
BIOS in the client PC is loaded into RAM 332 (see FIG. 3) of the client PC from 
which that code is then executed by the PC. This operational mode is denoted by 
block 425 shown in FIGS. 4A and 4B. At this point, as symbolized by block 430, the 
client PC is not aware of its IP address. The client PC then reads the boot code 
from a ROM situated on the NIC (or alternatively on the motherboard of the client 
PC itself) into RAM 332 and then executes that code — this operational mode denoted 
by block 450. In response to this code, the client PC will broadcast, as symbolized 
by line 432, a BootP (or DHCP) request packet over the network to elicit a response 
from a BootP (or DHCP) server. Illustratively, server 50 contains BootP server 232. 
This packet contains the hardware address of the NIC. For exemplary purposes, I 
will assume that address is "00A024Baf 9a5" . BootP server 232, which is a 
conventional TCP server, permits a network device, such as the NIC, to obtain its 
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own IP address (i.e., here an IP address assigned to client PC 10), the name of a 
boot file to download, an IP address of a network server (here server 50) on which 
that boot file is located, and (where appropriate) an IP address of a default 
router. BootP server 232 does not download the boot file itself; that occurs, as 
will be shortly seen by TFTP server 402 executing within server 50. The IP address 
of the device can also be obtained through a DHCP request packet. DHCP is a newer 
protocol than BootP, and builds on and replaces BootP. Inasmuch as the BootP and 
DHCP protocols are conventional and well-known, I will not discuss them in any 
further detail. In that regard, for further information, the reader is referred to 
Chapter 19, "Booting Internet Hosts with BootP and TFTP" on pages 343-359 of P. 
Miller, TCP/IP Explained ( . COPYRGT . 1997 , Digital Press ) --hereinafter the "Miller" 
text; and Chapter 16, "BOOTP: Bootstrap Protocol" on pages 215-222 of W. R. 
Stevens, TCP/IP Illustrated, Volume 1 — The Protocols (. COPYRGT . 1994 , Addison-Wesley 
Inc.). Both of these chapters are incorporated by reference herein. Since, for 1 
purposes of the present invention, either the BootP or DHCP protocols can be used 
with identical results, then, to simplify the ensuing discussion, I will omit any 
further reference to use of the DHCP protocol. The BootP server utilizes BOOTPTAB 
file 500. This file, illustratively shown in FIG. 5A, contains an entry for each of 
a number of remotely bootable devices that can connect to the network. Each such 
entry, such as entry 520 within entries 510, specifies for a single associated 
device: a hardware address (ha), i.e., a MAC, for that device; an associated boot 
file (bf) for that device; a home directory (hd) on that server which contains the 
boot file; and an IP address (ip) to assign to that device. For ease of access, the 
boot file and home directory reside on the same server as the BOOTPTAB file, here 
server 50. While the network may contain multiple BootP servers (of which, for 
simplicity, only one of which is shown in FIGS. 4A and 4B) , each remotely bootable 
device, such as a given NIC, has only one unique corresponding entry in only one 
BOOTPTAB file. In this manner, a broadcast BootP request appearing on the network 
from a given device will engender only one response from a single server that has 
an entry, in its BOOTPTAB file, that contains a MAC matching that contained in the 
request . 

Detailed Description Text (21) : 

In any event, after the client PC appropriately processes the BootP reply, the 
client PC will then know, as symbolized by block 440, its IP address. Next, as 
symbolized by line 442, the PC will issue, through the NIC, a TFTP request 

(typically a TFTP read command) to server 50, specifically TFTP server 402 thereon, 
to download the boot file identified in the BootP reply packet. If the TFTP server 
can locate and open this file based on the information provided in the TFTP 
request, then, as symbolized by line 444, TFTP server 402 will download the boot 
file to client PC 10. Once the boot file has been completely downloaded into RAM 
332 (see FIG. 3) on client PC 10, this PC will acknowledge a successful download by 
issuing, as symbolized by line 446 shown in FIGS. 4A and 4B, a TFTP acknowledgement 

(ACK) packet, back to server 50. With the boot file (LANHD. IMG) residing, as 
symbolized by block 460, in the client PC and after the ACK packet is issued, the 
client PC will begin executing the boot file from RAM 332 to implement client hard 
disk emulation. At this point, client PC 10 begins operating, as symbolized by 
block 470, under control of the downloaded boot file (LANHD. IMG) and ceases 
operating under the ROM boot code previously downloaded from, e.g., the NIC . 

Detailed Description Text (22) : 

The boot file, early in its execution, will cause the client PC to issue -a-TFPT 
request, as symbolized by line 462, back to server 50 to download an initialization 
file, specifically LANHD . INI file 550. This initialization file, as shown in FIG. 
5B, also contains a series of entries. Here, each such entry, of which entry 560 is 
typical, contains a MAC, an IP address of a server that stores a client image file 
for the device having that MAC and a complete path to the client image file (here 
file 414 on server 410) on that server. A LANHD. INI file entry also contains an 
illustrative term, such as "3c90x" or "3c5x9", which merely describes a name of the 
NIC associated with that entry and is ignored, as a comment field, during 
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subsequent processing of this file by the client PC. A further parameter (db) in 
entry 560 defines a default boot option (illustratively set to A or C) which is not 
relevant here. Once the download, as symbolized by line 4 64, completes, client PC 
10 will then generate and transmit, as symbolized by line 466, a TFTP ACK packet, 
over the network back to server 50. Furthermore, once this file has been 
downloaded, the client PC, under control of the boot file, LANHD.IMG, will process 
this file by first checking the contents of this file to determine whether an entry 
in the file contains a MAC that matches that of the NIC in the client PC. When an 
entry having a matching MAC is found, as illustratively occurs here, the boot file 
will then extract, from that entry, the full path to the client image file (here C: 
. backslash . LANHD . backslash . disklSO ) and the IP address (here 132.147.001.001) of a 
network server (here server 410) on which the client image file resides. Once 
client PC 10 obtains this information from the initialization file, the client PC, 
specifically executing the boot file (LANHD.IMG) which is then performing client 
hard disk emulation, issues, as symbolized by line 475, an RATFTP request to 
network server 410 to download a boot sector from client PC image file 414 residing 
thereon. 

Detailed Description Text (26) : 

During the boot process and prior to the availability of any client O/S-based 
network support, client hard disk emulation occurs, as discussed above in 
conjunction with LANHD.IMG operation shown in FIGS. 4A and 4B, through appropriate 
calls made to Interrupt 13 (Int 13) handler 623. Through such calls, appropriate 
sectors in the client image file are downloaded, via real-mode NIC driver 625 and 
Int 13 Handler 623 to remotely install various components of 0/S 690 into client 
PC. The actual client hard disk emulation process is provided through Real Mode 
Procedure 900 that executes as part of Int 13 Handler 623. In essence, procedure 
900 determines, based on values of status flags, whether the client 0/S is then 
capable of handling a network request for sector access of the client image file. 
If the client O/S has not then progressed to that point in its boot process, 
procedure 900 processes that request, in real mode, through Int 13. The remainder 
of this handler is conventional in nature. 

Detailed Description Text (27) : 

In particular, as shown in start-up sequence 710, upon power-up of the client PC, 
this PC commences operation using real-mode processing, as symbolized by line 752. 
This mode of operation persists through downloading and initiation of the boot 
loader and client hard disk emulation code, i.e., boot file LANHD.IMG; and 
commencement of loading 32-bit client 0/S 690 (e.g., Windows 95 O/S) . Here, client 
hard disk emulation with sector-by-sector downloading is provided by block 620, 
specifically Int 13 Handler 623 and real-mode NIC driver 625. 

Current US Cross Reference Classification (1) : 
709/217 ~~ ^ 

Current US Cross Reference Classification (2) : 
709/220 
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[57] 



ABSTRACT 



A technique, specifically apparatus and accompanying 
methods, for use in a client-server environment for booting 
an operating system (O/S), such as a 32-bit personal com- 
puter (PC) O/S, on a client computer through a networked 
connection to a server. Specifically, the server stores an 
image of a client hard disk including the client O/S and 
desired applications. During a boot process, a procedure, 
which is compliant with both an interrupt handler in the 
client and a network driver kernel in the client O/S, is 
installed in the client. Based on client O/S resources then 
available when, during the boot process, the client requests 
a local hard disk access to a particular sector, the procedure 
will re-direct that request, to the network file server, through 
a network driver kernel in the client O/S rather than through 
a client interrupt handler. Each such request is processed, to 
provide physical sector read or write access, through my 
inventive random access trivial file transfer protocol 
(RATFTP) server executing in the network server. 
Advantageously, the source of the sectors remains transpar- 
ent to the client O/S, while it is being booted from a network 
connection, in lieu of a local hard disk drive. Hence, client 
hard disk emulation occurs seamlessly and continuously 
throughout the entire boot process even though, during this 
process, the client processing mode changes from real to 
protected and the client O/S resets and gains control of a 
client network adapter. 

39 Claims, 14 Drawing Sheets 
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DOCUMENT-IDENTIFIER: US 5764896 A 

TITLE: Method and system for reducing transfer latency when transferring data from 
a network to a computer system 

Brief Summary Text (9) : 

Data is typically transferred across network segments in the form of packets or 
frames. A NIC usually includes a buffer or the like for temporarily storing data 
transferred between a computer system and a network. A key parameter for 
determining the performance of data .transmission is data transfer latency from the 
network to the computer system. Latency is a measure of the amount of time or delay 
to transfer a packet or packet portion to the main memory of the computer, and may 
further include the additional time to inform the host processor of the transfer, 
if necessary. In many Ethernet and token ring schemes prior to the present 
invention, an entire block of data was written into the buffer for temporary 
storage before being transferred to the main memory. Each block formed a portion of 
a packet or the entire packet and is typically approximately one kilobyte in 
length. Transfer of each block from the NIC to the main memory depended upon 
whether the NIC was capable of performing direct memory access (DMA) data 
transfers. If so, after a block was written to the buffer of the NIC, the NIC 
gained control of the expansion bus of the computer and performed a DMA transfer of 
the block into the computer memory. For memory-mapped configurations, the NIC 
informed the host processor, usually by interrupt, and the host processor 
controlled the transfer of the data from the buffer to the computer memory. 

Current US Original Classification (1) : 
709/250 

Current US Cross Reference Classification (1) : 
709/233 

Current US Cross Reference Classification (2) : 
709/235 
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[57] ABSTRACT 

A computer system for communicating with a network 
including a host processor, memory, an interface bus and a 
network interface device for reducing data transfer latency 
between the computer system and the network. The network 
interface device includes a buffer for temporarily storing 
data, a media interface device for transferring data between 
the buffer and the network, a bus interface for transferring 
data between the computer system's memory and the buffer, 
and a local processor for writing a unique value at a 
predetermined location within the buffer, for periodically 
comparing the data value at the predetermined location with 
the unique value and for initiating data transfer from the 
buffer to the computer's memory when the data value does 
not match the unique value. The network interface device is 
preferably a network interface card (NIC) for plugging into 
a slot of the interface or expansion bus of the computer 
system The local processor writes the unique value at the 
location and then periodically compares the data at that 
location with the unique value. When the data value is 
different from the unique value, the local processor has 
detected new data in that block of memory. The local 
processor respondingly initiates data transfer of the new data 
from that block to the memory of the computer system 

20 Claims, 3 Drawing Sheets 
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